Various abbreviations that may appear in the specification and/or in the drawing figures are defined as follows:
3GPPThird Generation Partnership ProjectBSSBase Station SystemEDGEEnhanced Data Rates for Global EvolutionGSMGlobal System for Mobile communicationsGERANGSM/EDGE Radio Access NetworkBCCHbroadcast control channelBABCCH allocationRXLEVreceived signal levelBSICbase station identity codeMSmobile station (also referred to as a UE)UTRANuniversal terrestrial radio access networkEUTRANevolved UTRAN (LTE)LTElong term evolution Node B base stationeNBEUTRAN Node B (evolved Node B)UEuser equipment (also referred to as a MS)ULuplink (UE towards eNB)DLdownlink (eNB towards UE)RLCradio link controlRRCradio resource controlRRMradio resource managementMACmedium access controlFDDfrequency division duplexOFDMAorthogonal frequency division multiple accessSC-FDMAsingle carrier, frequency division multiple accessPLCIDphysical layer cell identificationARFCNabsolute radio frequency channel numberEARFCNE-UTRA absolute radio frequency channel numberSACCHslow associated control channelPACCHpacket associated control channelPDTCHpacket data traffic channelNcellneighbor cellNCLneighbor cell list
A proposed communication system known as evolved UTRAN (EUTRAN, also referred to as UTRAN-LTE or as E-UTRA) is currently under development within 3GPP. The current working assumption is that the DL access technique will be OFDMA, and the UL access technique will be SC-FDMA.
One specification of interest is 3GPP TS 36.300, V8.3.0 (2007-12), 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Access Network (E-UTRAN); Overall description; Stage 2 (Release 8), which is attached hereto as Exhibit A and incorporated by reference herein in its entirety.
Another specification document that is of interest herein is 3GPP TS 44.018 V8.2.0 (2008-03) Technical Specification 3rd Generation Partnership Project; Technical Specification Group GSM/EDGE Radio Access Network; Mobile radio interface layer 3 specification; Radio Resource Control (RRC) protocol (Release 8). Of particular interest is subclause 10.5.2.20 “Measurement results”, and subclause 9.1.55, “Enhanced Measurement Report”, attached hereto as Exhibit B and incorporated by reference, as is the entirety of 3GPP TS 44.018 V8.2.0.
Reference may also be made to, for example, 3GPP TS 36.104 V8.1.0 (2008-03) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA); Base Station (BS) radio transmission and reception (Release 8), attached hereto as Exhibit C and incorporated by reference in its entirety.
FIG. 1 herein reproduces Figure 10.5.2.20.1, “Measurement Results information element” of 3GPP TS 44.018.
UTRAN FDD measurement reporting has thus far been standardized on the basis of a full neighbor cell list (a so-called “white list”, where individual cells are listed with a sufficient identification that is unique within a restricted geographical area). This permits an efficient reference to reported cells by using an index to the cell position in the neighbor cell list.
In the case of LTE interworking, a preference has been indicated for a so-called “black list” that is based on a neighbor cell list (NCL). In this approach the LTE center frequency would be indicated (in practice, the physical layer cell ID (PLCID) and the center frequency would be the minimum amount of information needed to uniquely identify a cell). In certain special cases, such as country border areas, a list of individual cells may be given where “not allowed” cells are indicated. In such a case the MS needs to determine which cells appear at each indicated frequency, and sufficient cell identification then needs to be sent to the network along with the actual measurement results.
The use of the black list implies that the center frequencies and possibly the physical layer cell id of not allowed (disallowed) EUTRAN cells are given in the EUTRAN Neighbor Cell list (NCL). The list can be considered to be black because the MS does not know the identities of the allowed EUTRAN neighbor cells from the NCL. In contradistinction, the use of the white list would imply that the allowed EUTRAN cells were given in the EUTRAN Neighbor Cell list, that is, as a minimum the center frequency and physical layer cell ID for each cell.
In further detail, for the white list approach when a measurement report was made for an EUTRAN Ncell, an index to the Neighboring Cell's entry in the NCL could simply be used, as opposed to having to identify the center frequency and the PLCID. This would result in fewer bits being needed for a measurement report, as compared to the use of the black list. For the white list approach each measurement report for an EUTRAN cell would consist of the NCL Index and the measurement result.
However, if the black list approach is to be used instead each measurement report would require the center frequency (or index), the PLCID and the measurement result. That is, the EUTRAN cell measurement results thus would include the center frequency indication (E-ARFCN, defined in 3GPP TS 36.104), the PLCID and the measurement result per cell. The center frequency may be indicated with, for example, a 3-bit index that refers to a list of EUTRAN center frequencies. A total of 6 bits may be sufficient for the measurement result, and the PLCID would require 9 bits. The implication of this is that approximately 18 bits would be needed for each reported EUTRAN cell.
Discussed now are problems with the MEASUREMENT REPORT and PACKET MEASUREMENT REPORT messages.
Generally, there is an interest in avoiding changes to existing signaling messages if at all possible. As a result, the UTRAN measurement reporting is specified such that the GERAN MEASUREMENT REPORT message (see 3GPP TS 44.018, subclause 10.5.2.20 (Exhibit B herein)) was not changed when the support for UTRAN reporting was standardized.
The details of the Measurement Results information elements are provided in Table 10.5.2.20.1, and are as follows:
BA-USED (octet 2), the value of the BA_IND field of the neighbour cell descriptioninformation element or elements defining the BCCH allocation used for the coding of BCCH-FREQ-NCELL fields. Range 0 to 1.DTX-USED (octet 2) This bit indicates whether or not the mobile station used DTXduring the previous measurement period.Bit 70DTX was not used1DTX was usedRXLEV-FULL-SERVING-CELL and RXLEV-SUB-SERVING-CELL, (octets 2 and3) Received signal strength on serving cell, measured respectively on all slots and on a subset ofslots (see 3GPP TS 45.008)The RXLEV-FULL-SERVING-CELL and RXLEV-SUB-SERVING-CELL fields arecoded as the binary representation of a value N. N corresponds according to the mapping definedin 3GPP TS 45.008 to the received signal strength on the serving cell.Range: 0 to 63MEAS-VALID (octet 3)This bit indicates if the measurement results for the dedicated channel are valid or notBit 70The measurement results are valid1the measurement results are not valid3G-BA-USED (octet 3)The value of the 3G_BA_IND field of the neighbour cell description information element orelements defining the 3G Neighbour Cell list used for the coding of 3G BCCH-FREQ-NCELLfields. Range 0 to 1.RXQUAL-FULL-SERVING-CELL and RXQUAL-SUB-SERVING-CELL (octet 4)Received signal quality on serving cell, measured respectively on all slots and on a subset of theslots (see 3GPP TS 45.008)CELL fields are coded as the binary representation of the received signal quality on theserving cell.Range: 0 to 7 (See 3GPP TS 45.008)NO-NCELL-M, Number of neighbour cell measurements (octets 4 and 5)Bits1 8 7Neighbour cell measurement result0 0 0None0 0 110 1 020 1 131 0 041 0 151 1 061 1 1Neighbour cell information not available for serving cellRXLEV-NCELL i, Result of measurement on the i'th neighbour cell (octet 5, 7, 8, 9, 10,11, 12, 13, 14, 15 and 16)If the i'th neighbour cell is a GSM cell, the RXLEV-NCELL field is coded as the binaryrepresentation of a value N. N corresponds according to the mapping defined in 3GPP TS 45.008to the received signal strength on the i'th neighbouring cell. See note 1 & 2.If the i'th neighbour cell is a 3G cell, the contents of the RXLEV-NCELL field is definedin 3GPP TS 45.008.Range: 0 to 63.Report on GSM cells:BCCH-FREQ-NCELL i, BCCH carrier of the i'th neighbour cell (octet 6, 8, 10, 12, 14, 15,16 and 17).The BCCH-FREQ-NCELL i field is coded as the binary representation of the position,starting with 0, of the i'th neighbour cells BCCH carrier in the BCCH channel list. The BCCHchannel list is composed of one or two BCCH channel sub lists, each sub list is derived from theset of frequencies defined by reference neighbour cell description information element or elements.In the latter case the set is the union of the two sets defined by the two neighbour cell descriptioninformation elements.In each BCCH channel sub list the absolute RF channel numbers are placed in increasingorder of ARFCN, except that ARFCN 0, if included in the set, is put in the last position in the sublist. The BCCH channel list consists either of only the sub list derived from the neighbour celldescription information element(s) in System Information 2/5 (and possible 2bis/5bis) or of thatsub list immediately followed by the sub list derived from the neighbour cell descriptioninformation element in System Information 2ter/5ter for the case System Information 2ter/5ter isalso received. If the set of ARFCNs defined by the reference neighbour cell descriptioninformation element or elements includes frequencies that the mobile station does not support thenthese ARFCNs shall be included in the list.The notation 2/5 etc. means that the rules above apply to the neighbour cell descriptioninformation elements received in System Information 2, 2bis and 2ter and to those received inSystem Information 5, 5bis and 5ter separately.See note 1 & 2.Range: 0 to 31/30.Report on 3G cells:If no more than 31 (GSM) ARFCN frequencies are included in the BA (list), the indexBCCH-FREQ-NCELL 31 indicates report(s) on 3G cells.In this case, the corresponding ‘BSIC-NCELL’ field in FIG. 10.5.2.20.1 carries the indexof the i'th 3G neighbour cell in the 3G Neighbour Cell list defined in sub-clause 3.4.1.2.1.1,“Deriving the 3G Neighbour Cell list from the 3G Neighbour Cell Description”. 3G cells withindexes above 63 are not reported (6 bits field).If more than 31 (GSM) ARFCN frequencies are included in the BA (list), reporting of 3Gcells is not possible with this IE.Range: 0 to 63.BSIC-NCELL i, Base station identity code of the i'th neighbour cell (octet 6, 7, 8, 9, 10,11, 13, 15 and 17)For GSM cells, the BSIC-NCELL i field is coded as the binary representation of the basestation identity code of the i'th neighbour cell. See note 1 & 2.Range: 0 to 63.NOTE 1:If the field extends over two octets the highest numbered bit of the lowest numbered octet is the most significant and the lowest numbered bit of the highest numbered octet is the least significant.NOTE 2:If NO-NCELL-M < 6 the remaining RXLEV-NCELL i, BS-FREQ-NCELL i and BSIC-NCELL i fields (NO-NCELL-M < i <= 6) shall be coded with a “0” in each bit.
It can be noted that each neighbor cell report in the GERAN measurement report message consists of 17 bits of information containing: a 6-bit RXLEV_NCELL, a 5-bit BCCH_FREQ_NCELL (containing the BA Index value), and a 6-bit BSIC_NCELL.
The approach taken for reporting 3G/UTRAN cell measurements in the GERAN system was to reserve one BA (BCCH Allocation) index value (‘31’) to indicate that the reported results are for UTRAN. The GERAN RXLEV field (6 bits) is replaced with the relevant UTRAN measurement result, and the GERAN BSIC field (6 bits) is used to carry an index to the 3G neighbor cell list. This last procedure is made possible because a full white list NCL is used for UTRAN, and thus the use of a simple index to the UTRAN neighbor cell list is made possible.
However, if the above-described black list approach is adopted for reporting EUTRAN cell measurements the 18 bits information as discussed above would need to be carried by the 12 bits of available space (from the RXLEV and BSIC fields) for each report in the measurement results IE (see again FIG. 1) used in the MEASUREMENT REPORT message. As should be appreciated this approach would not be usable even if one were to accept some performance compromise, such as a reduced measurement reporting range.
A similar problem occurs with the PACKET MEASUREMENT REPORT message (see 3GPP TS 44.060, subclause 11.2.9 (Exhibit D)) if no extension of the message is made.
FIG. 2 reproduces Figure 9.1.55.1. “Enhanced Measurement Report message content” of 3GPP TS.44.018, subclause 9.1.55 (see Exhibit B), which is another option for measurement reporting during a circuit switched (CS) connection. The details of the Enhanced Measurement Report (EMR) information elements are provided in Table 9.1.55.1, and are as follows:
BA_USED (1 bit field),The value of the BA-IND field of the neighbour cell description information element or elementsdefining the BCCH allocation used. Range 0 to 1.3G_BA_USED (1 bit field)The value of the 3G-BA-IND field of the neighbour cell description information element orelements defining the 3G allocation used. Range 0 to 1.BSIC_Seen (1 bit field)This parameters indicates if a GSM cell with invalid BSIC and allowed NCC part of BSIC is oneof the six strongest, see 3GPP TS 45.008.Bit0No cell with invalid BSIC and allowed NCC part of BSIC is seen1One Cell or more with invalid BSIC and allowed NCC part of BSIC is seenSCALE (1 bit field)The value of this field is defined in 3GPP TS 45.008.Serving cell reportingIf this structure is missing, this indicates that no valid measurement exist for the servingcell.Parameters RXLEV_VAL (6 bits), RX_QUAL_FULL (3 bits), MEAN_BEP (5 bits),CV_BEP (3 bits), NBR_RCVD_BLOCKS (5 bits) are defined in 3GPP TS 45.008.DTX_USED (1 bit field)This bit indicates whether or not the mobile station used DTX during the previous measurementperiod.0DTX was not used1DTX was used.Neighbour cell reportingRepeated Invalid BSICThis structure contains the report of cells with invalid BSIC.BCCH-FREQ-NCELL (5 bits). This field represents the index of the BA (list), see 10.5.2.20.BSIC (6 bits). Base station identity code of the corresponding index in the BA (list).RXLEV (6 bits). GSM reporting quantity, see 3GPP TS 45.008.Bitmap type reporting:This structure contains the report of cells with valid BSIC.Each bit of the bitmap points to the corresponding index of the Neighbour Cell list defined in sub-clause 3.4.1.2.1.3 ‘Deriving the Neighbour Cell list from the GSM Neighbour Cell list and the3G Neighbour Cell list’.If this structure is present and more bits than needed are available at the end of themessage, the MS shall set the value of the redundant bitmap positions to ‘0’.At least 96 neighour cell entries shall be encoded in the bitmap.If this structure is present, some remaining bits indicating no report at the end of themessage may be omitted if these bits do not fit into the message. This shall not lead to an error inthe receiver of that message.REPORTING_QUANTITY (6 bits):Measurement quantities are defined in 3GPP TS 45.008.
The EMR message is defined to be sent from the mobile station to the network to report enhanced measurement results. The Enhanced Measurement Report (EMR) message structure (see 3GPP TS 44.018 and FIG. 2 herein) does not allow extensions, specifically if the neighbor cell list is overly long (from GERAN and UTRAN cells). On the SACCH the Enhanced Measurement Report message cannot be segmented.
Another standards document that is of interest herein is 3GPP TS 44.060 V8.0.0 (2008-03) Technical Specification 3rd Generation Partnership Project; Technical Specification Group GSM/EDGE Radio Access Network; General Packet Radio Service (GPRS); Mobile Station (MS)-Base Station System (BSS) interface; Radio Link Control/Medium Access Control (RLC/MAC) protocol (Release 8). Of particular interest is subclause 11.2.9d “Packet Enhanced Measurement Report”, attached hereto as Exhibit D and incorporated by reference, as is the entirety of 3GPP TS 44.060 V8.0.0.
The problems inherent in the Enhanced Measurement Report message of 3GPP TS 44.018 are also of concern to the Packet Enhanced Measurement Report message of 3GPP TS 44.060.
As was noted above, in general there is an interest to avoid changes if possible to existing signaling messages. However, in that message extensions are not in practice feasible for the EMR message, a new message would need to be defined for reporting E-UTRAN measurement results.